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SECTION  I 


INTRODUCTION 


SUMMARY 

In  accomplishing  its  mission,  the  Air  Force  operates  and 
maintains  a $2  billion  fleet  of  100,000  ground  vehicles  at  some  500 
sites  around  the  world.  The  services  of  more  than  8,500  officer, 
airman,  and  civilian  maintenance  specialists  are  needed  to  keep  this 
fleet  in  readiness, 

A significant  segment  of  this  work  force  spends  much  of  its  time 
collecting,  evaluating,  and  disseminating  maintenance  management 
data,  aided  today  by  the  Vehicle  Integrated  Management  System 
(VIMS),  A standard  base-level  system,  VIMS  processes  vehicle 
maintenance  5a ta  in  daily  batches  on  the  Burroughs  B3500  computer: 
the  daily,  weekly,  and  monthly  reports  it  produces  support  the 
management  function  at  both  the  maintenance  squadron  and  higher 
headquarters  levels. 

As  developer  of  VIMS  software  and  procedures,  the  Directorate  of 
Logistics  at  the  Air  Force  Data  Systems  Design  Center  requested  in 
FY7^  that  ESD/MITRE  conduct  a brief  analysis  of  the  system  to 
uncover  possible  alternative  techniques  for  improved  handling  of 
maintenance  data,  (Results  are  reported  in  ESD-TR-75-1, 

”Air  Force  Vehicle  Integrated  Management  System  Data  Handling 
Study,”)  A primary  conclusion  of  the  study  was  that  the  maintenance 
management  function  could  benefit  from  on-line  access  to  VIMS,  This 
verdict  delivered,  the  study  group  was  subsequently  asked  to 
undertake  an  FY75  effort  to  collect  sufficient  data  on  which  to  base 
an  AFDSDC  decision  as  to  whether  or  not  to  proceed  with  development 
of  a prototype  on-line  VIMS,  The  study  group  was  also  tasked  to 
provide  system  development  guidelines  should  an  affirmative  decision 
be  made.  The  four  volumes  of  ESD-TR-75-301  report  the  results  of 
these  studies. 

The  work  proceeded  in  several  overlapping  phases:  A 

transaction-oriented,  man/machine  interface  (on-line  language  and 
scenarios)  was  designed;  this  transactional  specification  was 
transformed  into  a set  of  minicomputer  software  specifications,  and 
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a model*  on-line  VIMS  was  developed  to  operate  on  the  Nova  800 
computer  in  ESD/MITRE's  Data  Handling  Applications  Center;  prototype 
on-line  VIMS  development  guidelines  were  formulated;  functional 
personnel  (prospective  on-line  VIMS  users  drawn  from  vehicle 
maintenance  activities)  were  recruited  from  the  field  to  work  with 
the  model,  and  their  comments, in  combination  with  the  transactional 
specification,  form  the  basis  of  a revised  system  specification. 

After  hands-on  experience  with  the  model,  functional  personnel 
agreed  that  on-line  access  to  VIMS  would 

• improve  both  accuracy  and  currency  of  maintenance  data, 

• speed  execution  of  currently  manual  tasks,  and 

• maximize  efficiency  of  personnel  by  converting  time  spent 
at  repetitive  clerical  work  into  valuable  extra  hours 

of  management  and  analytical  activity. 


Without  doubt,  the  key  factor  in  the  model's  enthusiastic 
acceptance  by  prospective  users  was  the  natural  way  it  assumed  its 
role  within  an  envelope  of  familiar  procedures,  eliminating  many 
manual  record  keeping  tasks,  yet  leaving  undisturbed  the  current 
"ways  of  doing  business"  and  the  prerogatives  of  the  individual 
specialist. 

Volume  II  of  this  series  details  the  model  specifications,  test 
procedures  and  results.  Volume  III  documents  model  software  and  data 
files.  Volume  IV  presents  prototype  development  guidelines,  and 
this  volume  (I)  covers  these  same  subjects  in  highly  compressed 
form.  The  remainder  of  this  section  summarizes  the  current 
maintenance  data  management  environment  as  supported  by  batch  mode 
VIMS,  and  outlines  the  conduct  of  the  model  development  and 
evaluation  project. 


*Note:  It  is  important  to  recognize  the  distinction  between  model 

and  prototype.  The  model  was  built  to  Simula te  the  external 
representation  of  an  operational  system  for  prospective  users,  to 
gain  an  appreciation  of  how  an  on-line  system  might  best  be 
assimilated  into  the  vehicle  maintenance  environment.  Simulation  of 
external  characteristics  does  not  require  use  of  a number  of 
processing  steps  and  files  needed  to  support  an  operational  system. 
If  a prototype  is  developed,  it  would  represent  the  first 
installation  of  what  would  eventually  become  more  than  100  similar 
systems  supporting  vehicle  maintenance  throughout  the  Air  Force. 
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CURRENT  VEHICLE  MAINTENANCE  DATA  MANAGEMENT 


An  estimated  15%  of  all  Air  Force  vehicles  are  brought  to 
maintenance  facilities  at  least  once  a month,  either  for  scheduled 
preventive  maintenance  or  for  unscheduled  repair.  Maintenance 
operations  at  most  major  facilities  are  coordinated  by  a group  of 
four  to  seven  specialists  assigned  to  the  Maintenance  Control  work 
center.  (See  Figure  1.)  Personnel  assigned  to  Workload  Control 
screen  and  classify  maintenance  problems,  prepare  work  orders  for 
execution  by  the  shops,  schedule  workloads  into  the  shops,  and 
maintain  status  on  work  in  progress.  The  Materiel  Control  function 
is  concerned  with  the  acquisition  and  issuance  of  replacement  parts. 

Under  direct  control  of  the  Base  Transportation  Officer,  the 
Reports  and  Analysis  section  (R&A)  is  the  focal  point  of  the  maintenance 
data  flow  network  (See  Figure  2.),  and  is  the  primary  paper  work 
interface  between  the  maintenance  organization  and  the  current  VIMS 
system.  For  example,  R&A  collects  work  order,  parts,  gasoline,  and 
manhour  data  from  Maintenance  Control  and  the  shops,  provides  the 
keypunching  services  needed  to  create  input  for  the  VIMS  daily  run, 
and  monitors  and  distributes  VIMS  outputs  (vehicle  and  maintenance 
status  listings).  As  well,  it  furnishes  the  Maintenance  Officer 
with  management  data  identifying  trends  in  maintenance  costs,  per- 
sonnel performance,  vehicle  down  time,  and  similar  indicators. 

As  with  any  data  system,  incorrect  or  incomplete  VIMS  inputs 
from  work  or  control  centers  result  in  the  generation  of  inaccurate 
or  late  reports,  which  in  turn  can  damage  the  credibility  of  the 
system  and  tempt  users  to  institute  various  manual  record  keeping 
schemes  as  a back-up  measure.  Additionally,  given  VIMS's  current 
end-of-day  processing  orientation,  there  are  built-in  delays  which 
often  prevent  correction  of  erroneous  files  and  reports  until 
several  days  after  incorrect  inputs  have  been  detected  by  the 
system. 

Based  on  these  observations,  the  notion  of  providing  on-line 
access  to  the  VIMS  system  appeared  attractive  immediately,  because: 

• Input  data  could  be  screened  by  system  edit  software  at 
input  time,  with  discrepancies  called  to  the  user^s  attention 
immediately. 

• Much  of  the  fixed  information  required  to  formulate  a VIMS 
transaction  could  be  supplied  directly  from  system  files  and 
be  displayed  at  the  user’s  on-line  terminal,  saving  consi- 
derable manual  retranscription  with  a consequent  reduction 
in  the  probability  of  transcription  errors. 
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Figure  1.  Vehicle  Maintenance  Organization 
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Figure 


• With  the  ability  to  update  files  directly  and  immediately 
in  response  to  on-going  maintenance  events,  on-line  access 
could  guarantee  upgraded  currency  of  vehicle  and  work-in- 
progress status  information. 

• Providing  a two-way  dialogue  during  transaction  formulation, 
an  on-line  system  could  prompt  the  usejr  through  all  applica- 
ble input  and  decision  steps,  noting  omissions  of  mandatory 
items,  and  bringing  attention  to  optional  steps  which  the 
user  might  otherwise  ignore  (a  check  on  possible  repetitive 
repair  of  a particular  vehicle  component,  for  example). 

Aware  of  the  potential  value  of  these  kinds  of  capabilities,  the 
study  group  planned  and  executed  the  model  development  and 
evaluation  project  as  outlined  below. 

CONDUCT  OF  THE  PROJECT 

Figure  3 summarizes  the  relationships  among  the  project  tasks. 

An  extensive  observation  and  analysis  of  current  maintenance  data 
management  techniques  (based  on  the  current  VIMS  system)  was 
conducted  during  FY7^,  yielding  a description  of  the  baseline 
(batch)  system  which  was  validated  by  AFDSDC.  Building  upon  this, 
the  study  group  identified  particular  phases  of  maintenance  data 
management  which  could  profit  from  on-line  support,  and  wrote  a 
preliminary  system  specification  in  the  form  of  a set  of 
transactional  scenarios.  (Opening  a work  order,  or  issuing  a part, 
for  example).  Each  scenario  was  designed  primarily  around  the 
source  documents  and  procedures  of  the  current  system,  with  a 
cathode  ray  tube  display/keyboard  and  video  facsimiles  of  familiar 
forms  replacing  the  user's  pencil  and  paper.  (This  conservative 
design  approach  was  carried  over  into  the  implementation  of  the 
model,  and  became  the  single  strongest  factor  behind  its  rapid 
acceptance  by  functional  personnel). 

While  one  segment  of  the  study  group  translated  the  preliminary 
specification  into  a set  of  software  requirements  for  the  model 
system,  another  segment  addressed  the  prototype  development  planning 
process,  identifying  prototype  hardware/software  options,  design 
concepts,  preliminary  performance  projections,  and  development 
planning  tasks  and  schedules.  (The  work  is  presented  in  Volume  IV 
of  this  series) . 

The  model  system  was  implemented  on  a Data  General  minicomputer 
(Nova  800)  with  a Cathode  Ray  Tube  (CRT) /keyboard  terminal  manufactured 
by  Delta  Data  Systems  (Telterm  5200)  operating  at  2400  bps. 
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Figure  4 shows  the  terminal  screen  and  keyboard.  (The  keyboard 
resembles  that  of  a conventional  typewriter  with  the  addition  of  a 
duplicate  set  of  numeric  keys  grouped  together  in  the  fashion  of  a 
standard  calculator.  Additionally,  a set  of  special  function  keys 
is  provided  for  screen  cursor  movement  and  for  transmission  of  non- 
data signals  to  the  system;  transaction  complete,  input  line 
complete,  line  cancel,  etc.) 

Use  of  a CRT/keyboard  as  the  primary  user  input/output  device 
was  another  conservative  design  decision  which  was  proven  correct 
during  model  test  and  evaluation.  The  need  for  more  exotic  data 
capture  technology  has  yet  to  be  established  for  the  application, 
although  future  experiments  might  establish  a need.  Badge  readers 
and  similar  terminals  could  be  used  within  the  shops  for  job 
tracking,  for  example.  In  most  instances  today,  however, 
supervisors  have  adequate  knowledge  of  job  status.  In  addition, 
resistance  to  such  close  time-keeping  could  be  expected  where  not 
even  time-clocks  are  in  common  use.  The  U.  S.  Department  of 
Transportation's  National  Highway  Safety  Transportation 
Administration  is  reportedly  conducting  an  extensive  investigation 
of  the  costs  and  benefits  of  using  advanced  automated  diagnostic 
tests,  with  results  to  be  available  during  1977*  (Computerworld,  5 
March  1975,  page  3.2.)  These  results  can  help  the  Air  Force  decide 
how  to  proceed  with  such  techniques. 

The  design  and  interrelationships  of  the  model's  software 
modules  and  data  files  are  described  in  Volume  III  of  this  series. 
With  the  on-line  VIMS  model  in  operation,  both  study  group  and 
functional  personnel  exercised  the  transactional  scenarios  specified 
earlier,  providing  useful  comments  on  the  preliminary  system 
specification  (presented  with  the  test  and  evaluation  procedures  in 
Volume  II  of  this  series).  Three  groups  of  functional  personnel 
spent  one  week  each  performing  model  test  and  evaluation.  In  each 
group  were  representatives  from  Workload  Control,  Materiel  Control, 
and  Reports  and  Analysis,  and  a wide  range  of  commands  was 
represented:  SAC,  AFSC,  USAFE,  TAC,  and  MAC.  In  all,  ten  functional 
personnel  interacted  with  the  model  during  the  test  and  evaluation 
phase,  providing  design  guidance  based  on  a total  of  155  years  of 
Air  Force  maintenance  experience. 

Not  only  were  these  prospective  users'  specific  suggestions 
valuable  in  refining  the  system's  man/machine  interfaces,  they  also 
confirmed  the  previously  suspected  value  of  a basic  on-line 
capability.  Typical  comments  gathered  during  debriefing  sessions 
included  the  following; 
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Figure  4,  On-Line  Terminal 


• ’’•••bringing  errors  to  your  attention  immediately  will  save 
I time  and  manhours,” 

• ’’...less  chance  of  paperwork  being  lost  or  mislaid,” 

• ”...it  will  move  most  of  the  input  to  its  source... and  give 
R&A  more  time  to  do  their  real  job^” 

Looking  beyond  the  immediate  success  of  the  on-line  VIMS  model 
test  and  evaluation,  both  project  staff  and  functional  personnel 
agreed  that  the  system  modeling  approach  in  general  holds  great 
promise  for  the  future.  A working  model  of  an  on-line  system, 
developed  quickly  at  no  great  cost,  is  the  most  efficient  means  to 
gather  the  professional  reactions  of  the  specialists  who  will 
ultimately  use  the  system:  the  sooner  these  reactions  can  be 
factored  into  the  system  design,  the  greater  the  chance  that  the 
system  will  succeed  in  the  field. 
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SECTION  II 


ON-LINE  VIMS  MODEL  TEST  AND  EVALUATION 


SUMMARY 

The  primary  result  of  model  testing  was  the  capture  of  a large 
number  of  specific  comments  and  suggestions  from  prospective  users 
that  will  serve  as  guidance  for  any  subsequent  development  of  on- 
line VIMS. 

Acceptance  of  the  on-line  approach  was  uniformly  high  among  all 
ten  test  subjects  because  1)  current  manual  procedures  were  strongly 
paralleled  in  the  on-line  procedures,  2)  the  on-line  procedures 
provided  some  immediate  and  apparent  benefits  to  the  user,  and  3) 
the  model  design  allowed  the  user  to  feel  comfortably  in  control  of 
the  computer. 

It  was  concluded  that  the  development  and  testing  of  a model  by 
functional  personnel  is  a highly  effective  approach  to  system 
design. 

THE  MODEL  AND  THE  TEST  ENVIRONMENT 

The  model  is  composed  of  a set  of  computer  programs  that  respond 
to  and  interact  with  a user  as  he  performs  a variety  of  on-line  VIMS 
transactions,  initiated  and  controlled  from  a CRT  terminal.  The 
modeled  transactions  represent  procedures  that  would  be  followed  at 
terminals  located  in  the  three  work  centers  mentioned  previously; 
Workload  Control,  Materiel  Control,  and  R&A.  In  addition  to  the  CRT 
terminal,  a printer  would  be  available  to  each  work  center  to  obtain 
immediate  hard  copy  as  needed. 

The  model  software  was  written  in  ALGOL  for  the  Data  General 
NOVA  minicomputer  at  the  ESD/MITRE  Data  Handling  Applications 
Center.  The  Center  supports  a NOVA  800  with  32,768  words  of  l6-bit 
core  memory,  and  a large  selection  of  peripheral  devices  running 
under  Data  General ^s  Real-time  Disk  Operating  System.  (Volume 
III  of  this  series  presents  detailed  descriptions  of  the  model ^s 
hardware  and  software  components.) 

The  seven  files  making  up  the  model ^s  test  data  base  were 
configured  to  reflect  the  typical  maintenance  status  of  a fleet  of 
TOO  vehicles.  The  content  and  structure  of  the  files  were  selected 
for  expediency  in  developing  the  model,  and  do  not  represent  the 
content  or  structure  of  the  files  that  would  be  required  for  a 
prototype  system.  Thus  the  test  files  contain  only  a subset  of  the 
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data  required  for  a prototype,  and  are  maintained  and  updated  by  the 
model  only  to  the  extent  necessary  to  preserve  the  realism  and 
integrity  of  the  transaction  modules  as  viewed  by  a user  at  a 
terminal. 

The  files  developed  for  the  model  include: 

a.  VEHICLE  MASTER*  Contains  data  for  100  vehicles.  Includes 
static  data  for  each  vehicle  and  complete  scheduled 
maintenance  data.  (This  file  was  created  using  actual  data 
for  100  vehicles  from  the  fleet  at  Hanscom  AFB) . 

b.  VEHICLE  HISTORICAL  REPAIR.  Contains  maintenance  repair 
history  for  100  vehicles  over  six  months. 

c.  EMPLOYEE  MASTER.  Contains  employee  name,  SSAN,  and 
assigned  work  center  for  30  employees. 

d.  HIGH  COST  BENCH  STOCK.  Contains  FSN's,  cost,  charge  codes 
and  descriptions  of  120  high  cost  bench  stock  items  (taken 
from  HCBS  file  at  Hanscom  AFB). 

e.  WORK  ORDER.  Contains  copies  of  all  work  orders  currently 
open,  suspended,  or  closed  less  than  six  days  (the  file  was 
initially  loaded  with  32  work  orders,  simulating  two  days 
of  activity) . 

f.  DEFERRED  MAINTENANCE.  Contains  a record  of  all  jobs  either 
deferred  or  suspended  (the  file  was  loaded  with  26  jobs, 
deferred  against  20  vehicles). 

g.  BACK-ORDERED  PARTS.  Contains  data  on  all  parts  on  order, 
or  back-ordered  and  received  but  not  yet  installed  (the 
file  was  loaded  with  data  for  31  parts,  ordered  against  22 
jobs) . 

h.  PARTS  WARRANTY.  Contains  data  on  all  parts  installed  on 
fleet  vehicles  for  which  a special  warranty  is  still 
current  (the  file  was  loaded  with  36  warranty  items). 

The  proposed  on-line  VIMS  transactions  do  not  represent  a major 
departure  from  the  current  batch-oriented  VIMS  procedures:  the 
transactions  are  generally  designed  to  assist  with  specific  tasks 
presently  performed  at  the  work  centers  in  the  vehicle  maintenance 
area. 
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The  testing  with  functional  personnel  was  intended  to  determine 
if  the  on-line  procedures  as  specified  and  modeled  could  permit 
users  to  properly  complete  their  tasks,  and  whether  on-line 
dialogues,  visual  display  formats  and  content,  and  data  entry 
conventions  were  operationally  acceptable. 


The 

following  transactions  were  incorporated  in  the  model: 

a. 

OPEN,  Used  to  ooen  a work  order. 

b* 

RESUME,  Used  to  resume  ooeninc  a work  order  temoorarilv 
suspended. 

c • 

AMEND,  Used  to  retrieve  an  ooen  work  order  for  review 
and/or  amendment. 

d. 

VDP/ON.  Suspend  a work  order  and  out  vehicle  on  VDP 
(vehicle  down  for  parts)  status. 

e. 

VDP/OFF,  Remove  a vehicle  from  VDP  status,  and  reactivate 
a work  order. 

f. 

CLOSE,  Close  a work  order  and  report  disposition  of  all 
Jobs. 

g* 

WO/REVIEW,  Display  status  of  all  work  orders. 

h. 

DEFER/ADD  (CHANGE) (DELETE) . Used  to  make  direct  additions, 
changes  and  deletions  to  the  deferred  maintenance  file. 

i. 

PARTS/REVIEW,  Display  back-ordered  parts  file. 

PARTS/ADD  (CHANGE) (DELETE).  Used  to  make  additions, 
changes  and  deletions  to  the  back-ordered  parts  file. 

k. 

PARTS/ISSUE.  Issue  parts  out  of  the  back-ordered  parts 
file  against  a work  order. 

1. 

HCBS/REVIEW.  Display  hiKh  cost  bench  stock  file. 

m* 

HCBS/ADD  (CHANGE) (DELETE) . Used  to  add.  chanKe  or  delete 
items  from  the  high  cost  bench  stock  master  file. 

n. 

HCBS/ISSUE.  Issue  high  cost  bench  stock  items  against  work 
orders. 
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o.  CQPARS»  Used  to  process  COPARS  (Contractor  Operated  Parts 
Store)  sales  slips. 

p.  FUEL.  Process  fuel/oil  issue  slips. 

q.  TIME/INPUT  (EDIT).  Process  employee  time  cards,  and 
process  error  suspense  file  generated  during  TIME/INPUT. 

Figure  5 is  one  example  of  the  kinds  of  formats  provided  at  the 
terminal  to  aid  the  model  user  in  completing  transaction  input.  The 
format  shown  is  used  to  accomplish  a work  order  OPEN  and  contains 
data  describing  six  maintenance  jobs. 

USER  TEST  AND  EVALUATION 

Table  I summarizes  the  composition  of  the  three  teams  of 
functional  personnel  which  exercised  the  on-line  VIMS  model  during 
April  of  1975. 

When  each  team  arrived  it  was  given  about  an  hour  of 
introductory  discussion.  Field  personnel  were  assured  that  they 
were  not  being  tested  or  evaluated  in  any  way.  It  was  emphasized 
that  they  were  to  help  evaluate  a proposed  system  in  its  early 
development  stage,  and  that  their  comments  would  provide  guidance 
that  would  help  to  shape  the  final  system  when  and  if  it  were  to  be 
implemented. 

Subjects  were  introduced  to  the  concept  of  on-line  VIMS  and  the 
nature  of  the  model  was  explained.  The  model  was  described  as  a 
"fast  file  clerk,"  able  to  perform  many  routine  clerical  tasks 
rapidly  and  consistently.  It  was  emphasized  that  the  operator  of 
the  CRT  was  always  in  control,  and  always  retained  the  decision- 
making prerogative;  the  "file  clerk"  was  there  to  assist  only  as 
directed. 

Two  observers  (a  MITRE  technical  staff  member  and  a 
representative  of  AFDSDC)  recorded  comments  throughout  the 
introductory,  training  and  testing  periods.  At  any  time  during 
testing,  specific  points  were  addressed  and  talked  through  as  they 
came  up. 

The  subjects  themselves  also  wrote  their  own  comments  during  the 
discussion  periods,  during  testing  (when  they  were  acting  as 
observers),  and  during  off  hours.  Each  subject  also  filled  out  an 
evaluation  questionnaire  at  the  completion  of  the  testing. 
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WORK  ORDER  NO  (4226)  VEHICUE  REG  NOC69B01922)  DATE  OPENED (74327)  TIME(0806) 
MGT  COOE(B204)  MAKE/TYPE (P-U  CHE)  DATE  COMPLETEO(  ) TIME(  ) 
R/D  CODE(  ) MILEAGE  EXCEEDED(  ) AGE  EXCEEDED(  ) 

PRI0RITY(Y  ) MILES/HRS (064230)  USER  PH0NE(4782  ) WORK  ORDER  TYPE(F) 
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Figure  5.  Work  Order  as  Initially  Displayed  During  OPEN 


Test  Subjects;  Duty  Station,  Work  Center  Assignment, 

Air  Force  Experience  and  Test  Team  Assignment 
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of  Years  Air  Force  Experience 


An  oral  debriefing  was  conducted  with  each  team  at  the  end  of 
its  test  period.  These  debriefing  sessions  were  tape  recorded  and 
the  tapes  were  given  to  the  AFDSDC  representative. 

Almost  400  comments  were  recorded.  These  were  numbered,  sorted 
and  categorized,  primarily  by  the  transaction  to  which  they 
pertained,  and  further  sorted  by  sub-category  within  transaction.  A 
separate  category  was  created  for  comments  regarding  the 
CRT/keyboard  and  for  requests  and  suggestions  regarding  special 
reports  and  inquiries.  These  comments  represent  a large  volume  of 
specific  guidance  that  could  serve  as  input  to  the  development  of 
specifications  for  a prototype  on-line  VIMS.  Volume  II  of  this 
series  presents  both  the  procedural  details  of  each  transaction  and 
the  reactions  of  the  field  personnel  to  them. 

In  general,  acceptance  of  the  model  system  by  functional 
personnel  was  surprisingly  good.  In  retrospect  it  appears  that  the 
following  factors  were  responsible: 

a.  The  proposed  on-line  capability  does  not  represent  a major 
departure  from  current  procedure.  The  user's  terminal  primarily 
assists  him  in  completing  tasks  which  he  is  already  performing  in 
the  manual  system.  As  a result,  there  is  a strong  parallel  between 
present  and  proposed  methods. 

b.  In  addition  to  keeping  vehicle  maintenance  management  data 
more  current  and  accurate,  the  transactions  generally  offer  some 
direct  and  immediate  benefits  to  the  user,  such  as  fast  file 
retrievals,  automatic  calculations,  immediate  error  checking, 
automatic  status  posting,  etc. 

c.  The  user's  view  of  the  on-line  system  as  a "fast  file 
clerk"  to  assist  in  performing  designated  tasks,  leaves  him  with  the 
feeling  that  he  is  in  control  rather  than  being  driven  by  the 
computer.  This  is  enhanced  by  the  fact  that  the  user  can  always 
resort  to  a QUIT  function  key  at  any  time  to  nullify  any  transaction 
no  matter  how  far  he  has  progressed  with  it  (short  of  actual 
completion) . 

Comments  made  by  subjects  during  test  and  evaluation  indicate 
that  they  were  pleased  with  the  responsiveness  of  the  model  system. 
It  should  be  noted  that  the  model  implementation  of  the  system 
provides  optimum  responsiveness,  since  1)  it  operates  on  a dedicated 
computer,  2)  the  data  files  are  small,  3)  line  speed  (between 
terminal  and  computer)  is  2400  bps,  and  4)  a high  speed  printer  is 
used  for  hardcopy  production.  To  the  extent  that  any  of  these 
factors  may  degrade  in  an  operational  implementation,  system 
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responsiveness  will  degrade  accordingly.  There  must  certainly  be  a 
response  threshold  which,  when  exceeded,  would  render  the  system 
unacceptable  to  the  user,  regardless  of  any  benefits  promised. 

While  this  testing  made  no  attempt  to  measure  user  tolerance  to 
degraded  response,  this  is  certainly  an  important  factor  to  be 
considered  in  subsequent  design  and  implementation  planning. 

THE  MODEL  APPROACH 

Finally,  the  project  staff  believes  that  the  development  of  the 
model  and  subsequent  testing  by  functional  personnel  has  shown 
modeling  to  be  an  effective  approach  to  system  design.  Construction 
of  a model  forces  system  designers  to  a level  of  detail  that  is 
difficult  to  accomplish  on  paper  alone.  It  also  forces  early 
consideration  of  the  relationships  and  interdependencies  of  the 
pieces  of  a system. 

The  model  proved  to  be  an  excellent  vehicle  for  involving 
potential  users  in  design  discussions.  Although  imperfect,  the 
model  is  tangible  and  is  far  more  thought  stimulating  than  a design 
document.  By  getting  potential  users  really  involved  in  the  early 
stages  of  system  design,  there  is  a much  better  opportunity  to  shape 
a final  system  that  will  be  responsive  to  user  needs.  The  resulting 
system  will  require  fewer  modifications  and  retrofits,  and  should 
meet  with  wider  user  acceptance  by  acknowledging  more  closely  in  the 
design  the  real  world  in  which  it  will  operate. 

Looking  beyond  the  VIMS  model,  the  following  section  presents 
some  important  factors  in  planning  for  development  of  a prototype 
system. 
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SECTION  III 


PROTOTYPE  DEVELOPMENT  PLANNING 


INTRODUCTION 

As  noted  earlier,  the  ‘‘prototype”  system  is  assumed  to  be  the 
first  operational  version  installed  in  the  field,  the  forerunner  of 
more  than  100  similar  installations.  Volume  IV  of  this  series 
presents  the  detail  lying  behind  this  summary. 

Fortunately,  VIMS  functions  today  as  a working  data  system 
operating  on  the  B3500  in  batch  mode.  This  circumstance,  combined 
with  others,  provides  a set  of  practical  planning  constraints. 

Major  factors  are: 

• The  strong  risks  incurred  in  totally  abandoning  the  B3500 
as  the  currently  successful  processor  of  VIMS  master  files. 

• The  necessity  of  preserving  the  stability  of  batch  VIMS 
software  and  data  products  during,  and  possibly  after, 
transition  to  an  on-line  mode  of  operation.  Periodic  batch 
reports  would  still  be  needed  not  only  for  vehicle 
maintenance  management  but  also  as  backup  documentation  for 
the  on-line  system. 

• AFDSDC/LGTV 's  desire  for  an  early  on-line  capability  as 
reflected  in  its  planning  for  a prototype  implementation  by 
October,  1977. 

• The  imminence  of  a major  base-level  ADPE  (BLADPE)  upgrade 
under  auspices  of  the  BASE-TOP  and  STALOG  programs. 

Current  expectations  call  for  program  planning  to  be 
essentially  completed  by  1977-78.  Such  an  upgrade  might 
involve  replacement  or  significant  enhancement  of  the 
B3500. 

The  method  used  to  derive  development  recommendations  involves 
definition  of  four  basic  alternatives  which  must  be  evaluated  in 
light  of  several  criteria  of  corresponding  generality. 

BASIC  ALTERNATIVES 

Figure  6 defines  four  alternatives  for  development  of  the  on- 
line VIMS  prototype  and  indicates  some  relationships  among  them. 

Note  that  each  alternative  must  ultimately  deal  with  the  advent  of 
new  base-level  ADPE.  New  BLADPE  may  take  the  form  of  a single  base 
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Figure  6.  Prototype  Development  Options 
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computer,  a central  base  computer  augmented  by  functionally-oriented 
minicomputers,  or  complete  dispersal  of  base  processing  to 
functional  minis# 

The  first  alternative  calls  for  no  action  on  prototype 
development  until  new  BLADPE  has  been  specified  in  some  detail# 

This  is  essentially  a non-option  in  view  of  the  constraint  to 
provide  an  on-line  capability  as  soon  as  practically  possible. 
However,  due  to  unforeseen  changes  in  funding,  technical,  or 
institutional  circumstances,  inaction  cannot  be  dismissed  as  a 
possibility.  The  secon.d  alternative  (0LV3500)  calls  for  an  on-line 
prototype  supported  solely  by  the  B3500.  The  third  alternative 
(OLVHYB)  is  a hybrid  VIMS  prototype  with  real-time  file  processing 
assumed  by  a front-end-processor  (FEP)  minicomputer,  and  the  fourth 
(OLVDED)  calls  for  development  of  the  prototype  on  a dedicated 
minicomputer  after  a transitional  implementation  of  OLVHYB.  NOTE: 
The  term  ’’dedicated”  refers  to  the  equipment's  relationship  to  on- 
line VIMS,  not  to  its  relationship  with  other  base-level  processors. 
It  is  presumed  that  any  minicomputer  supporting  VIMS  would  be  linked 
via  communications  to  other  computers  to  the  extent  that  data 
exchange  or  mutual  back-up  requirements  would  dictate,  and  that  any 
residual  processing  capacity  could  be  used  to  support  other  elements 
of  the  logistics  commmunity. 

Although  OLVDED  presumes  an  eventual  transition  from  OLVHYB  to 
FEP-only  operation,  such  a transition  would  not  take  place  until 
after  adequate  experience  had  been  gained  with  FEP  equipment,  a new 
operating  system,  and  with  use  of  on-line  VIMS  in  general.  Figure  7 
illustrates  these  transitonal  steps. 

Note  that  the  specified  development  sequence  begins  with  an 
analysis  of  the  B3500  as  the  prototype  host  computer,  and  that  the 
succeeding  alternative  calls  for  retention  of  some  file  processing 
on  the  B3500.  This  is  an  essentially  conservative  position  based  on 
the  hope  that  much  of  today's  batch  VIMS  software  could  be  used  to 
support  the  on-line  version  of  the  system.  Use  of  current  software 
is  highly  desirable  because  it  would 

• Lessen  the  expense  and  technical  risk  incurred  in  the  on- 
line system  implementation  effort, 

• Reduce  the  possibility  of  damage  to  VIMS  data  bases, 

• Preserve  the  continuity  of  proven  batch  data  products,  and 

• Assure  availability  of  updated  VIMS  master  files  for  use  in 
batch  mode  as  back-up  in  event  of  on-line  system  failure. 
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Figure  7.  Prototype  Design  Concept 


(Volume  IV  describes  a hybrid  file  configuration  which 
could  permit  retention  of  some  current  VIMS  software.) 

The  arrows  leading  from  alternative  to  alternative  in  Figure  6 
indicate  a progression  of  analysis  and  preliminary  system  design, 
with  arrival  at  any  one  choice  dependent  upon  evaluation  of  each  of 
the  preceding  alternatives.  Such  analyses  require  use  of  evaluation 
criteria: 

• Performance 

• Cost 

• Technical  Risk 

Whatever  prototype  development  strategy  is  selected,  the 
decision  must  be  based  on  an  acceptable  balance  of  cost, 
performance,  and  technical  risk,  including  the  probable 
compatibility  of  the  prototype  implementation  with  future  BLADPE. 

EVALUATION  CRITERIA 

Performa nee  - .The  performance  criterion  is  concerned  with  the 
timeliness  with  which  the  on-line  system  responds  to  user  commands. 
Because  of  the  data  management  (as  opposed  to  computational) 
orientation  of  on-line  VIMS,  system  performance  will  equate  to  file 
access  performance.  Some  of  the  time  expended  in  file  processing  is 
keyed  to  storage  device  performance  (disk  latency,  transfer  rate). 

By  far  the  greatest  access  delays  are  encountered,  however,  during 
the  time  an  individual  read/write  request  must  wait  enqueued  until 
prior  requests  have  been  serviced.  This  means  that,  device 
performance  factors  being  equal,  the  less  software  contention  for 
storage  access  the  faster  the  rate  of  access  for  any  particular 
software  system. 

Cost  - Volume  IV  presents  the  method  used  to  cost  the 
development  options.  As  one  might  suspect,  development  program 
costs  vary  directly  with  the  amount  and  complexity  of  new  prototype 
software  which  must  be  written. 

Technical  Risk  - The  degree  of  technical  risk  presented  by  each 
alternative  equals  the  extent  to  which  its  successful  implementation 
is  threatened  by  technical  complexities  and  unknowns.  There  seem  to 
be  two  separate  sources  of  risk:  difficulty  of  transition  to  BLADPE, 
and  the  relative  magnitude  of  the  new  equipment  and  software  to  be 
incorporated  in  the  prototype  configuration. 
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CRITERIA  APPLIED 


Table  II  summarizes  the  evaluation  of  development  options  in 
light  of  the  criteria  defined  above. 

Performance 


0LV3500  performance,  although  potentially  acceptable,  (and 
currently  unknown),  would  be  poorer  than  that  provided  by  the  other 
alternatives  since  VIMS  software  would  have  to  compete  with  other 
B3500  users  for  file  access  facilities.  (This  would  be  the  case 
unless  VIMS  were  provided  with  a dedicated  on-line  storage  device 
and  data  channel.)  Given  an  FEP  to  process  high  activity  files, 
performance  of  OLVHYB  would  be  superior  to  that  of  OLV3500  since 
contention  by  other  systems  for  storage  access  would  occur  only  in 
the  B3500.  Use  of  a dedicated  minicomputer  would  further  reduce 
contention  by  non-VIMS  software. 

In  the  absence  of  a system  design,  the  performance  baseline 
represented  by  0LV3500  is  currently  inestimable.  Once  a rough 
design  is  postulated,  however,  the  number  of  random  access 
read/write  operations  per  transaction  type  will  be  established,  and 
these,  multiplied  by  projected  transaction  volumes,  can  then  yield 
total  storage  accesses  per  some  unit  time.  Matched  against  current 
B3500  response  time/storage  access  baselines  for  other  on-line 
systems,  these  figures  will  provide  some  clue  to  probable  OLV3500 
performance. 

Technical  Risk 


Development  risk  increases  with  use  of  unfamiliar  equipment  and 
system  software,  the  requirement  to  write  and  test  new  application 
software,  and  the  decision  to  abandon  use  of  proven  software. 
Hopefully,  risk  associated  with  an  OLVDED  implementation  would  be 
minimized  through  the  familiarity  with  new  equipment  and  software 
gained  during  the  OLVHYB  experience. 

Cost 


Volume  IV  contains  a detailed  breakdown  of  costs  by  development 
option  by  program  year. 

Summarized,  these  are: 
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Manpower 

Equipment 

Total 

Costs 

Costs 

Costs 

A 

0LV3500 

$ 395,200 

$ 12,000 

$ 407,200 

OLVHYB 

$ 904,800 

$112,000 

$1,016,800 

OLVDED 

$1,320,800 

$1 12,000 

$1,432,800 

Conclusions 


An  OLV3500  prototype  appears  cheapest  and  least  risky  to 
develop,  but  its  performance  will  be  unknown  until  a preliminary 
system  design  is  completed.  If  OLV35O0  performance  is  eventually 
projected  as  marginal  or  unacceptable,  then  OLVHYB  should  be 
considered  as  a means  to  relieve  the  B3500  of  most  real-time  file 
processing.  This  would  then  leave  the  option  open  to  progress  to 
OLVDED  for  ease  of  transition  to  new  BLADPE,  or  for  other  reasons. 

Presuming  OLV3500  performance  is  judged  adequate,  cost  and 
technical  risk  factors  must  be  inspected.  If  either  of  these  is 
unacceptable,  (with  OLVHYB  and  OLVDED  offering  progressively  higher 
cost  and  risk),  then  there  seems  to  be  no  choice  but  to  await 
specification  of  new  BLADPE  vrtiile  operating  VIMS  in  standard  batch 
fashion.  If  cost  and  risk  are. acceptable,  then  0LV3500  has 
qualified  as  an  alternative  and  the  decision  must  be  made  to  either 
move  ahead  with  an  OLV3500  implementation  or  to  qualify  OLVHYB  as 
another  candidate  through  analysis  and  preliminary  design. 

Summarizing  critical  prototype  development  objectives,  they  are: 

• Minimization  of  risk  and  cost  by  building  the  prototype  on 
top  of  proven  batch  VIMS  software  to  the  extent  possible. 

• Preservation  of  the  stability  of  the  current  system  during 
transition  to  on-line  operations. 

• Smooth  integration  of  on-line  VIMS  (in  whatever 
implementation)  with  (whatever  form  of)  upgraded  base-level 
ADPE  is  ultimately  implemented. 
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